The present invention relates to wireless communications, and more particularly to a method for implementing the Bluetooth Communication standard.
Along with the proliferation of handheld devices, cell phones, laptops, personal computers and other electronic devices comes a desire to enable those devices to communicate with one another without cumbersome and expensive wires between them. Thus, wireless technology is gaining popularity in the industry and is expanding rapidly. One of those technologies emerging from the various different proposals for implementing wireless communications is the so-called Bluetooth protocol. The Bluetooth protocol uses radio transmissions to transfer both voice and data in real-time. Bluetooth technology allows users to make effortless, wireless and instant communications between various wireless devices.
The Bluetooth system provides both point-to-point connections (only two Bluetooth devices involved), or point-to-multipoint connections (more than two Bluetooth devices). In the point-to-multipoint connection, a communication channel is shared among several Bluetooth devices. Two or more devices sharing the same channel form a “piconet.” In a piconet, one Bluetooth unit acts as the master of the piconet, whereas the other units act as slaves. The master controls access to the channel.
Multiple piconets with overlapping coverage areas form a “scatternet.” Each piconet has only one master; however a master in one piconet can be a slave in another piconet. This allows for continually flexible configurations. FIG. 1 is a simplified diagram illustrating a scatternet 100 with several Bluetooth devices networked in multiple piconets under the Bluetooth protocol. A first piconet 101 comprises devices 103, 105, 107, and 109. Device 103 is the master device while devices 105, 107 and 109 are slave devices. A second piconet 111 comprises devices 109, 113, and 115. In second piconet 111, device 109 is the master device (though it was the slave device in first piconet 101) and devices 113 and 115 are slave devices. A third piconet 117 is comprised of master device 119 and slave devices 115 and 121.
Each Bluetooth device includes a radio transceiver and a host processor. A link controller and a link manager provide the hardware and software interfaces respectively between the radio transceiver and the host processor. The Bluetooth protocol defines various functions that must be carried out to communicate between the master devices and the slave devices. Those functions are described in the Specification of the Bluetooth System; Ver 1.0B dated Dec. 1, 1999 which is incorporated by reference herein for all purposes. However, the Bluetooth protocol does not define specifically how those functions are to be carried out in the actual devices. One issue that arises in a design of those devices is the question of which functions are to be done in hardware and which functions are to be done in software. Of course, the answer involves trade-offs in design time, flexibility and testing. Because of the robust functionality of the Bluetooth protocol, a design done completely in hardware becomes very complex. That complexity leads to lots of hardware with its accompanying size, costs, power, testing, design, time-to-market, error correction and other problems. The known hardware designs to date that implement the link controller (Baseband) functionality in hardware are very large. On the other hand, a software implementation has difficulty in meeting the strict timing constraints placed upon the various tasks that are to be performed. Such systems use DSPs or very powerful CPUs to implement the Baseband functionality. Such processors are large by both size and gate count and consume lots of power. They also are expensive parts. Thus, it is desirable to design a system that finds a more appropriate balance between hardware and software.
Another issue that arises in design of complex hardware and software systems such as a Bluetooth protocol is the communication between the hardware and the software. One way in which software and hardware communicate is through the use of a scheduling table. In the past, the scheduling table has been implemented as a list of instructions to the hardware. Several instructions are typically written to the table well in advance of their actual execution. That is, the link manager sets it up in advance with a series of instructions that are executed sequentially. However, such a method involves the use of lots of hardware and is limited in its flexibility. Thus, a new method of communicating with a scheduling table is desirable.